home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000008_owner-urn-ietf _Mon Jan 13 12:55:39 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB

  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA06583 for urn-ietf-out; Mon, 13 Jan 1997 12:55:39 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA06578 for <urn-ietf@services.bunyip.com>; Mon, 13 Jan 1997 12:55:36 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA00951  (mail destined for urn-ietf@services.bunyip.com); Mon, 13 Jan 97 12:55:30 -0500
  5. Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
  6.           id <20698-0@josef.ifi.unizh.ch>; Mon, 13 Jan 1997 18:54:59 +0100
  7. Date: Mon, 13 Jan 1997 18:54:58 +0100 (MET)
  8. From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  9. To: Ryan Moats <jayhawk@ds.internic.net>
  10. Cc: urn-ietf@bunyip.com
  11. Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL 
  12.          syntax draft]
  13. In-Reply-To: <32D53ECE.1EBF@ds.internic.net>
  14. Message-Id: <Pine.SUN.3.95.970113184100.245U-100000@enoshima>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Thu, 9 Jan 1997, Ryan Moats wrote [regrouped]:
  23.  
  24. > Well, here we are in the week of 1/6/97 and some issues have come up
  25. > vis-a-vie the URL syntax document.  Here are the technical issues (as I
  26. > see them, and I've probably missed/ignored some):
  27. > 1. The URN syntax is more restrictive in the types of characters
  28. > allowed vis-a-vie the URL syntax.  Specifically, the characters
  29. > ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format)
  30. > in the URL syntax while not in the URN syntax.
  31.  
  32. > My current thoughts are to move the characters in note 1 above from the
  33. > excluded character set to the allowed character set to more closely
  34. > align the URN and URL character sets.  IF SOMEONE THINKS THIS IS A BAD
  35. > IDEA THIS IS A GOOD TIME TO LET ME KNOW!
  36.  
  37. With exception of "~", for which some change has been going on in
  38. the URL syntax draft, they should be in. The reasoning for this is
  39. that we don't know what kind of reserved characters a namespace would
  40. like to use, but we know that it can only use those that we include.
  41.  
  42.  
  43. > 2. The URL syntax document makes a claim that the its syntax is the
  44. > syntax for URIs in general so that URNs may be used in any data field
  45. > that might otherwise hold a URL.
  46. > I'll admit that there are a lot of political issues that I am ignoring
  47. > for now, but I want to see if we can move forward with the technical
  48. > issues.
  49.  
  50. > Issue 2 is handled (I believe) by adding an appendix to the URN syntax
  51. > document that covers how a URL resolver should react to a URN. My
  52. > proposal is that the URN be considered an opaque URL that gets handed
  53. > off to a URN resolver. There are alternate solutions, but they become
  54. > progressively more ugly.
  55.  
  56. Yes, this is a good way to describe it. Please make sure you don't
  57. write "an URL resolver SHOULD", but that you describe this as a possible
  58. way to proceed that clarifies the relationship between URLs and URNs.
  59.  
  60.  
  61.  
  62. > Note that issues 1 and 2 are somewhat independent.  Given the current
  63. > allowed characters and the above suggested appendix, any URN could be
  64. > used in place of a URL.  
  65. > Although I've considered it in the past, I think that defining URN's as
  66. > a URL "scheme" is a less optimal solution than the above proposals.
  67.  
  68. I agree we should not say that an URN is an URL "scheme".
  69. Syntactically, it is equivalent to an URL scheme, but semantically,
  70. it is something different.
  71.  
  72.  
  73. Regards,    Martin.
  74.